Cloud-based computing systems are configured to provide computing resources (e.g., RED HAT® Enterprise Linux instances) to multiple subscriber nodes, such as certified cloud providers. The efficient management of a cloud-based computing system usually includes the provisioning of certain update packages to the subscriber nodes relating to the operation of the cloud computing resources. The update package(s), also referred to as an update or an update stream, may be delivered to and consumed by the subscriber nodes that are operating in the cloud environment. For example, the update package may include information relating to enhancements, features, functionality, vulnerabilities, patches, and fixes relating to the computing resources.
An update package management system is typically employed to manage the packages and may include a horizontally-scalable distribution tier for delivery of the update packages, referred to as the content delivery servers (CDS). The delivery of update packages by the multiple CDSs to the subscriber nodes is typically managed and coordinated by an enterprise appliance, such as, for example, the RED HAT® Update Appliance (RHUA).
From the subscriber node perspective, it is desirable that the CDSs be both highly available and appropriately load-balanced to ensure the reliable and efficient downloading of the desired update package(s). In a conventional arrangement, the subscriber node may initiate a request (e.g., a yum command) to a CDS server to obtain a mirror list file. The minor list includes a prioritized listing of multiple CDSs assigned to a cluster which provides an ordered list of CDSs to contact to obtain the update packages. However, if the CDS server that is sent the request for the minor list is unavailable, the request fails, the mirror list can not be sent to the subscriber node, and the subscriber node can not engage in the update package acquisition process. Therefore, this arrangement has a single point of failure—the CDS server contacted by the subscriber node to obtain the mirror list.
In other conventional arrangements, requests from the subscriber nodes may be first directed to a single load balancer server configured to maintain the minor list, which may in turn use HTTP-based communications to forward the request to one or more CDSs in accordance with the minor list. However, like the system described above, if the initial load balancer server is unavailable, the subscriber node can not connect with a CDS to obtain the one or more update packages. Accordingly, the system includes a single point of failure and does not provide a high availability update stream.
Due to the elastic and scalable nature of the CDS tier wherein CDS instances may be added or removed (or otherwise become unavailable due to, for example, a hardware failure), there is a need to actively manage the CDS tier to ensure a proper load balancing amongst the CDSs and maintain high-available communication between the CDSs and the subscriber nodes. Particularly in the instance when a CDS is no longer available (i.e., the CDS is removed or fails), there is a need for fail-over protection and un-interrupted delivery of the one or more update packages to the subscriber nodes. However, conventional CDS tiers lack the ability to effectively account for an unavailable CDS while efficiently load balancing the available CDSs.